home *** CD-ROM | disk | FTP | other *** search
/ Internet Warrior 1993 July / Internet Warrior No. 1 July 1993 - Austin Code Works.ISO / docs / beginner / hitchike.txt < prev    next >
Encoding:
Text File  |  1993-04-11  |  60.1 KB  |  1,351 lines

  1. Request:  nsfnet
  2. Topic:    hgi
  3. Subject:  The Hitchhikers Guide to the Internet
  4. Date:     31 July 1990
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11. Network Working Group                                            E. Krol
  12. Request for Comments: 1118                 University of Illinois Urbana
  13.                                                           September 1989
  14.  
  15.  
  16.                  The Hitchhikers Guide to the Internet
  17.  
  18. Status of this Memo
  19.  
  20.    This RFC is being distributed to members of the Internet community in
  21.    order to make available some "hints" which will allow new network
  22.    participants to understand how the direction of the Internet is set,
  23.    how to acquire online information and how to be a good Internet
  24.    neighbor.  While the information discussed may not be relevant to the
  25.    research problems of the Internet, it may be interesting to a number
  26.    of researchers and implementors.  No standards are defined or
  27.    specified in this memo.  Distribution of this memo is unlimited.
  28.  
  29. NOTICE:
  30.  
  31.    The hitchhikers guide to the Internet is a very unevenly edited memo
  32.    and contains many passages which simply seemed to its editors like a
  33.    good idea at the time.  It is an indispensable companion to all those
  34.    who are keen to make sense of life in an infinitely complex and
  35.    confusing Internet, for although it cannot hope to be useful or
  36.    informative on all matters, it does make the reassuring claim that
  37.    where it is inaccurate, it is at least definitively inaccurate.  In
  38.    cases of major discrepancy it is always reality that's got it wrong.
  39.    And remember, DON'T PANIC.  (Apologies to Douglas Adams.)
  40.  
  41. Purpose and Audience
  42.  
  43.    This document assumes that one is familiar with the workings of a
  44.    non-connected simple IP network (e.g., a few 4.3 BSD systems on an
  45.    Ethernet not connected to anywhere else).  Appendix A contains
  46.    remedial information to get one to this point.  Its purpose is to get
  47.    that person, familiar with a simple net, versed in the "oral
  48.    tradition" of the Internet to the point that that net can be
  49.    connected to the Internet with little danger to either.  It is not a
  50.    tutorial, it consists of pointers to other places, literature, and
  51.    hints which are not normally documented.  Since the Internet is a
  52.    dynamic environment, changes to this document will be made regularly.
  53.    The author welcomes comments and suggestions.  This is especially
  54.    true of terms for the glossary (definitions are not necessary).
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62. Krol                                                            [Page 1]
  63.  
  64. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  65.  
  66.  
  67. What is the Internet?
  68.  
  69.    In the beginning there was the ARPANET, a wide area experimental
  70.    network connecting hosts and terminal servers together.  Procedures
  71.    were set up to regulate the allocation of addresses and to create
  72.    voluntary standards for the network.  As local area networks became
  73.    more pervasive, many hosts became gateways to local networks.  A
  74.    network layer to allow the interoperation of these networks was
  75.    developed and called Internet Protocol (IP).  Over time other groups
  76.    created long haul IP based networks (NASA, NSF, states...).  These
  77.    nets, too, interoperate because of IP.  The collection of all of
  78.    these interoperating networks is the Internet.
  79.  
  80.    A few groups provide much of the information services on the
  81.    Internet.  Information Sciences Institute (ISI) does much of the
  82.    standardization and allocation work of the Internet acting as the
  83.    Internet Assigned Numbers Authority (IANA).  SRI International
  84.    provides the principal information services for the Internet by
  85.    operating the Network Information Center (NIC).  In fact, after you
  86.    are connected to the Internet most of the information in this
  87.    document can be retrieved from the SRI-NIC.  Bolt Beranek and Newman
  88.    (BBN) provides information services for CSNET (the CIC) and NSFNET
  89.    (the NNSC), and Merit provides information services for NSFNET (the
  90.    NIS).
  91.  
  92. Operating the Internet
  93.  
  94.    Each network, be it the ARPANET, NSFNET or a regional network, has
  95.    its own operations center.  The ARPANET is run by BBN, Inc. under
  96.    contract from DCA (on behalf of DARPA).  Their facility is called the
  97.    Network Operations Center or NOC.  Merit, Inc. operates NSFNET from
  98.    yet another and completely seperate NOC.  It goes on to the regionals
  99.    having similar facilities to monitor and keep watch over the goings
  100.    on of their portion of the Internet.  In addition, they all should
  101.    have some knowledge of what is happening to the Internet in total.
  102.    If a problem comes up, it is suggested that a campus network liaison
  103.    should contact the network operator to which he is directly
  104.    connected.  That is, if you are connected to a regional network
  105.    (which is gatewayed to the NSFNET, which is connected to the
  106.    ARPANET...) and have a problem, you should contact your regional
  107.    network operations center.
  108.  
  109. RFCs
  110.  
  111.    The internal workings of the Internet are defined by a set of
  112.    documents called RFCs (Request for Comments).  The general process
  113.    for creating an RFC is for someone wanting something formalized to
  114.    write a document describing the issue and mailing it to Jon Postel
  115.  
  116.  
  117.  
  118. Krol                                                            [Page 2]
  119.  
  120. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  121.  
  122.  
  123.    (Postel@ISI.EDU).  He acts as a referee for the proposal.  It is then
  124.    commented upon by all those wishing to take part in the discussion
  125.    (electronically of course).  It may go through multiple revisions.
  126.    Should it be generally accepted as a good idea, it will be assigned a
  127.    number and filed with the RFCs.
  128.  
  129.    There are two independent categorizations of protocols.  The first is
  130.    the state of standardization which is one of "standard", "draft
  131.    standard", "proposed", "experimental", or "historic".  The second is
  132.    the status of this protocol which is one of "required",
  133.    "recommended", "elective", or "not recommended".  One could expect a
  134.    particular protocol to move along the scale of status from elective
  135.    to required at the same time as it moves along the scale of
  136.    standardization from proposed to standard.
  137.  
  138.    A Required Standard protocol (e.g., RFC-791, The Internet Protocol)
  139.    must be implemented on any host connected to the Internet.
  140.    Recommended Standard protocols are generally implemented by network
  141.    hosts.  Lack of them does not preclude access to the Internet, but
  142.    may impact its usability.  RFC-793 (Transmission Control Protocol) is
  143.    a Recommended Standard protocol.  Elective Proposed protocols were
  144.    discussed and agreed to, but their application has never come into
  145.    wide use.  This may be due to the lack of wide need for the specific
  146.    application (RFC-937, The Post Office Protocol) or that, although
  147.    technically superior, ran against other pervasive approaches.  It is
  148.    suggested that should the facility be required by a particular site,
  149.    an implementation be done in accordance with the RFC.  This insures
  150.    that, should the idea be one whose time has come, the implementation
  151.    will be in accordance with some standard and will be generally
  152.    usable.
  153.  
  154.    Informational RFCs contain factual information about the Internet and
  155.    its operation (RFC-1010, Assigned Numbers).  Finally, as the Internet
  156.    and technology have grown, some RFCs have become unnecessary.  These
  157.    obsolete RFCs cannot be ignored, however.  Frequently when a change
  158.    is made to some RFC that causes a new one to be issued obsoleting
  159.    others, the new RFC may only contains explanations and motivations
  160.    for the change.  Understanding the model on which the whole facility
  161.    is based may involve reading the original and subsequent RFCs on the
  162.    topic.  (Appendix B contains a list of what are considered to be the
  163.    major RFCs necessary for understanding the Internet).
  164.  
  165.    Only a few RFCs actually specify standards, most RFCs are for
  166.    information or discussion purposes.  To find out what the current
  167.    standards are see the RFC titled "IAB Official Protocol Standards"
  168.    (most recently published as RFC-1100).
  169.  
  170.  
  171.  
  172.  
  173.  
  174. Krol                                                            [Page 3]
  175.  
  176. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  177.  
  178.  
  179. The Network Information Center (NIC)
  180.  
  181.    The NIC is a facility available to all Internet users which provides
  182.    information to the community.  There are three means of NIC contact:
  183.    network, telephone, and mail.  The network accesses are the most
  184.    prevalent.  Interactive access is frequently used to do queries of
  185.    NIC service overviews, look up user and host names, and scan lists of
  186.    NIC documents.  It is available by using
  187.  
  188.       %telnet nic.ddn.mil
  189.  
  190.    on a BSD system, and following the directions provided by a user
  191.    friendly prompter.  From poking around in the databases provided, one
  192.    might decide that a document named NETINFO:NUG.DOC (The Users Guide
  193.    to the ARPANET) would be worth having.  It could be retrieved via an
  194.    anonymous FTP.  An anonymous FTP would proceed something like the
  195.    following.  (The dialogue may vary slightly depending on the
  196.    implementation of FTP you are using).
  197.  
  198.      %ftp nic.ddn.mil
  199.      Connected to nic.ddn.mil
  200.      220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT
  201.      Name (nic.ddn.mil:myname): anonymous
  202.      331 ANONYMOUS user ok, send real ident as password.
  203.      Password: myname
  204.      230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.
  205.      ftp> get netinfo:nug.doc
  206.      200 Port 18.144 at host 128.174.5.50 accepted.
  207.      150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
  208.      226 Transfer Completed 157675 (8) bytes transferred
  209.      local: netinfo:nug.doc  remote:netinfo:nug.doc
  210.      157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
  211.      ftp> quit
  212.      221 QUIT command received. Goodbye.
  213.  
  214.    (Another good initial document to fetch is NETINFO:WHAT-THE-NIC-
  215.    DOES.TXT).
  216.  
  217.    Questions of the NIC or problems with services can be asked of or
  218.    reported to using electronic mail.  The following addresses can be
  219.    used:
  220.  
  221.      NIC@NIC.DDN.MIL         General user assistance, document requests
  222.      REGISTRAR@NIC.DDN.MIL   User registration and WHOIS updates
  223.      HOSTMASTER@NIC.DDN.MIL  Hostname and domain changes and updates
  224.      ACTION@NIC.DDN.MIL      SRI-NIC computer operations
  225.      SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and services
  226.  
  227.  
  228.  
  229.  
  230. Krol                                                            [Page 4]
  231.  
  232. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  233.  
  234.  
  235.    For people without network access, or if the number of documents is
  236.    large, many of the NIC documents are available in printed form for a
  237.    small charge.  One frequently ordered document for starting sites is
  238.    a compendium of major RFCs.  Telephone access is used primarily for
  239.    questions or problems with network access.  (See appendix B for
  240.    mail/telephone contact numbers).
  241.  
  242. The NSFNET Network Service Center
  243.  
  244.    The NSFNET Network Service Center (NNSC), located at BBN Systems and
  245.    Technologies Corp., is a project of the University Corporation for
  246.    Atmospheric Research under agreement with the National Science
  247.    Foundation.  The NNSC provides support to end-users of NSFNET should
  248.    they have questions or encounter problems traversing the network.
  249.  
  250.    The NNSC, which has information and documents online and in printed
  251.    form, distributes news through network mailing lists, bulletins, and
  252.    online reports.  NNSC publications include a hardcopy newsletter, the
  253.    NSF Network News, which contains articles of interest to network
  254.    users and the Internet Resource Guide, which lists facilities (such
  255.    as supercomputer centers and on-line library catalogues) accessible
  256.    from the Internet.  The Resource Guide can be obtained via anonymous
  257.    ftp to nnsc.nsf.net in the directory resource-guide, or by joining
  258.    the resource guide mailing list (send a subscription request to
  259.    Resource-Guide-Request@NNSC.NSF.NET.)
  260.  
  261. Mail Reflectors
  262.  
  263.    The way most people keep up to date on network news is through
  264.    subscription to a number of mail reflectors (also known as mail
  265.    exploders).  Mail reflectors are special electronic mailboxes which,
  266.    when they receive a message, resend it to a list of other mailboxes.
  267.    This in effect creates a discussion group on a particular topic.
  268.    Each subscriber sees all the mail forwarded by the reflector, and if
  269.    one wants to put his "two cents" in sends a message with the comments
  270.    to the reflector.
  271.  
  272.    The general format to subscribe to a mail list is to find the address
  273.    reflector and append the string -REQUEST to the mailbox name (not the
  274.    host name).  For example, if you wanted to take part in the mailing
  275.    list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends a
  276.    request to NSFNET-INFO-REQUEST@MERIT.EDU.  This may be a wonderful
  277.    scheme, but the problem is that you must know the list exists in the
  278.    first place.  It is suggested that, if you are interested, you read
  279.    the mail from one list (like NSFNET-INFO) and you will probably
  280.    become familiar with the existence of others.  A registration service
  281.    for mail reflectors is provided by the NIC in the files
  282.    NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT, and
  283.  
  284.  
  285.  
  286. Krol                                                            [Page 5]
  287.  
  288. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  289.  
  290.  
  291.    NETINFO:INTEREST-GROUPS-3.TXT.
  292.  
  293.    The NSFNET-INFO mail reflector is targeted at those people who have a
  294.    day to day interest in the news of the NSFNET (the backbone, regional
  295.    network, and Internet inter-connection site workers).  The messages
  296.    are reflected by a central location and are sent as separate messages
  297.    to each subscriber.  This creates hundreds of messages on the wide
  298.    area networks where bandwidth is the scarcest.
  299.  
  300.    There are two ways in which a campus could spread the news and not
  301.    cause these messages to inundate the wide area networks.  One is to
  302.    re-reflect the message on the campus.  That is, set up a reflector on
  303.    a local machine which forwards the message to a campus distribution
  304.    list.  The other is to create an alias on a campus machine which
  305.    places the messages into a notesfile on the topic.  Campus users who
  306.    want the information could access the notesfile and see the messages
  307.    that have been sent since their last access.  One might also elect to
  308.    have the campus wide area network liaison screen the messages in
  309.    either case and only forward those which are considered of merit.
  310.    Either of these schemes allows one message to be sent to the campus,
  311.    while allowing wide distribution within.
  312.  
  313. Address Allocation
  314.  
  315.    Before a local network can be connected to the Internet it must be
  316.    allocated a unique IP address.  These addresses are allocated by
  317.    SRI-NIC.  The allocation process consists of getting an application
  318.    form.  Send a message to Hostmaster@NIC.DDN.MIL and ask for the
  319.    template for a connected address.  This template is filled out and
  320.    mailed back to the hostmaster.  An address is allocated and e-mailed
  321.    back to you.  This can also be done by postal mail (Appendix B).
  322.  
  323.    IP addresses are 32 bits long.  It is usually written as four decimal
  324.    numbers separated by periods (e.g., 192.17.5.100).  Each number is
  325.    the value of an octet of the 32 bits.  Some networks might choose to
  326.    organize themselves as very flat (one net with a lot of nodes) and
  327.    some might organize hierarchically (many interconnected nets with
  328.    fewer nodes each and a backbone).  To provide for these cases,
  329.    addresses were differentiated into class A, B, and C networks.  This
  330.    classification had to with the interpretation of the octets.  Class A
  331.    networks have the first octet as a network address and the remaining
  332.    three as a host address on that network.  Class C addresses have
  333.    three octets of network address and one of host.  Class B is split
  334.    two and two.  Therefore, there is an address space for a few large
  335.    nets, a reasonable number of medium nets and a large number of small
  336.    nets.  The high order bits in the first octet are coded to tell the
  337.    address format.  There are very few unallocated class A nets, so a
  338.    very good case must be made for them.  So as a practical matter, one
  339.  
  340.  
  341.  
  342. Krol                                                            [Page 6]
  343.  
  344. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  345.  
  346.  
  347.    has to choose between Class B and Class C when placing an order.
  348.    (There are also class D (Multicast) and E (Experimental) formats.
  349.    Multicast addresses will likely come into greater use in the near
  350.    future, but are not frequently used yet).
  351.  
  352.    In the past, sites requiring multiple network addresses requested
  353.    multiple discrete addresses (usually Class C).  This was done because
  354.    much of the software available (notably 4.2BSD) could not deal with
  355.    subnetted addresses.  Information on how to reach a particular
  356.    network (routing information) must be stored in Internet gateways and
  357.    packet switches.  Some of these nodes have a limited capability to
  358.    store and exchange routing information (limited to about 700
  359.    networks).  Therefore, it is suggested that any campus announce (make
  360.    known to the Internet) no more than two discrete network numbers.
  361.  
  362.    If a campus expects to be constrained by this, it should consider
  363.    subnetting.  Subnetting (RFC-950) allows one to announce one address
  364.    to the Internet and use a set of addresses on the campus.  Basically,
  365.    one defines a mask which allows the network to differentiate between
  366.    the network portion and host portion of the address.  By using a
  367.    different mask on the Internet and the campus, the address can be
  368.    interpreted in multiple ways.  For example, if a campus requires two
  369.    networks internally and has the 32,000 addresses beginning
  370.    128.174.X.X (a Class B address) allocated to it, the campus could
  371.    allocate 128.174.5.X to one part of campus and 128.174.10.X to
  372.    another.  By advertising 128.174 to the Internet with a subnet mask
  373.    of FF.FF.00.00, the Internet would treat these two addresses as one.
  374.    Within the campus a mask of FF.FF.FF.00 would be used, allowing the
  375.    campus to treat the addresses as separate entities. (In reality, you
  376.    don't pass the subnet mask of FF.FF.00.00 to the Internet, the octet
  377.    meaning is implicit in its being a class B address).
  378.  
  379.    A word of warning is necessary.  Not all systems know how to do
  380.    subnetting.  Some 4.2BSD systems require additional software.  4.3BSD
  381.    systems subnet as released.  Other devices and operating systems vary
  382.    in the problems they have dealing with subnets.  Frequently, these
  383.    machines can be used as a leaf on a network but not as a gateway
  384.    within the subnetted portion of the network.  As time passes and more
  385.    systems become 4.3BSD based, these problems should disappear.
  386.  
  387.    There has been some confusion in the past over the format of an IP
  388.    broadcast address.  Some machines used an address of all zeros to
  389.    mean broadcast and some all ones.  This was confusing when machines
  390.    of both type were connected to the same network.  The broadcast
  391.    address of all ones has been adopted to end the grief.  Some systems
  392.    (e.g., 4.3 BSD) allow one to choose the format of the broadcast
  393.    address.  If a system does allow this choice, care should be taken
  394.    that the all ones format is chosen.  (This is explained in RFC-1009
  395.  
  396.  
  397.  
  398. Krol                                                            [Page 7]
  399.  
  400. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  401.  
  402.  
  403.    and RFC-1010).
  404.  
  405. Internet Problems
  406.  
  407.    There are a number of problems with the Internet.  Solutions to the
  408.    problems range from software changes to long term research projects.
  409.    Some of the major ones are detailed below:
  410.  
  411.    Number of Networks
  412.  
  413.       When the Internet was designed it was to have about 50 connected
  414.       networks.  With the explosion of networking, the number is now
  415.       approaching 1000.  The software in a group of critical gateways
  416.       (called the core gateways) are not able to pass or store much more
  417.       than that number.  In the short term, core reallocation and
  418.       recoding has raised the number slightly.
  419.  
  420.    Routing Issues
  421.  
  422.       Along with sheer mass of the data necessary to route packets to a
  423.       large number of networks, there are many problems with the
  424.       updating, stability, and optimality of the routing algorithms.
  425.       Much research is being done in the area, but the optimal solution
  426.       to these routing problems is still years away.  In most cases, the
  427.       the routing we have today works, but sub-optimally and sometimes
  428.       unpredictably.  The current best hope for a good routing protocol
  429.       is something known as OSPFIGP which will be generally available
  430.       from many router manufacturers within a year.
  431.  
  432.    Trust Issues
  433.  
  434.       Gateways exchange network routing information.  Currently, most
  435.       gateways accept on faith that the information provided about the
  436.       state of the network is correct.  In the past this was not a big
  437.       problem since most of the gateways belonged to a single
  438.       administrative entity (DARPA).  Now, with multiple wide area
  439.       networks under different administrations, a rogue gateway
  440.       somewhere in the net could cripple the Internet.  There is design
  441.       work going on to solve both the problem of a gateway doing
  442.       unreasonable things and providing enough information to reasonably
  443.       route data between multiply connected networks (multi-homed
  444.       networks).
  445.  
  446.    Capacity & Congestion
  447.  
  448.       Some portions of the Internet are very congested during the busy
  449.       part of the day.  Growth is dramatic with some networks
  450.       experiencing growth in traffic in excess of 20% per month.
  451.  
  452.  
  453.  
  454. Krol                                                            [Page 8]
  455.  
  456. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  457.  
  458.  
  459.       Additional bandwidth is planned, but delivery and budgets might
  460.       not allow supply to keep up.
  461.  
  462. Setting Direction and Priority
  463.  
  464.    The Internet Activities Board (IAB), currently chaired by Vint Cerf
  465.    of NRI, is responsible for setting the technical direction,
  466.    establishing standards, and resolving problems in the Internet.
  467.  
  468.    The current IAB members are:
  469.  
  470.            Vinton Cerf          - Chairman
  471.            David Clark          - IRTF Chairman
  472.            Phillip Gross        - IETF Chairman
  473.            Jon Postel           - RFC Editor
  474.            Robert Braden        - Executive Director
  475.            Hans-Werner Braun    - NSFNET Liaison
  476.            Barry Leiner         - CCIRN Liaison
  477.            Daniel Lynch         - Vendor Liaison
  478.            Stephen Kent         - Internet Security
  479.  
  480.    This board is supported by a Research Task Force (chaired by Dave
  481.    Clark of MIT) and an Engineering Task Force (chaired by Phill Gross
  482.    of NRI).
  483.  
  484.    The Internet Research Task Force has the following Research Groups:
  485.  
  486.             Autonomous Networks            Deborah Estrin
  487.             End-to-End Services            Bob Braden
  488.             Privacy                        Steve Kent
  489.             User Interfaces                Keith Lantz
  490.  
  491.    The Internet Engineering Task Force has the following technical
  492.    areas:
  493.  
  494.            Applications                    TBD
  495.            Host Protocols                  Craig Partridge
  496.            Internet Protocols              Noel Chiappa
  497.            Routing                         Robert Hinden
  498.            Network Management              David Crocker
  499.            OSI Interoperability            Ross Callon, Robert Hagen
  500.            Operations                      TBD
  501.            Security                        TBD
  502.  
  503.    The Internet Engineering Task Force has the following Working Groups:
  504.  
  505.             ALERTMAN                       Louis Steinberg
  506.             Authentication                 Jeff Schiller
  507.  
  508.  
  509.  
  510. Krol                                                            [Page 9]
  511.  
  512. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  513.  
  514.  
  515.             CMIP over TCP                  Lee LaBarre
  516.             Domain Names                   Paul Mockapetris
  517.             Dynamic Host Config            Ralph Droms
  518.             Host Requirements              Bob Braden
  519.             Interconnectivity              Guy Almes
  520.             Internet MIB                   Craig Partridge
  521.             Joint Management               Susan Hares
  522.             LAN Mgr MIB                    Amatzia Ben-Artzi
  523.             NISI                           Karen Bowers
  524.             NM Serial Interface            Jeff Case
  525.             NOC Tools                      Bob Enger
  526.             OSPF                           Mike Petry
  527.             Open Systems Routing           Marianne Lepp
  528.             OSI Interoperability           Ross Callon
  529.             PDN Routing Group              CH Rokitansky
  530.             Performance and CC             Allison Mankin
  531.             Point - Point IP               Drew Perkins
  532.             ST and CO-IP                   Claudio Topolcic
  533.             Telnet                         Dave Borman
  534.             User Documents                 Karen Roubicek
  535.             User Services                  Karen Bowers
  536.  
  537. Routing
  538.  
  539.    Routing is the algorithm by which a network directs a packet from its
  540.    source to its destination.  To appreciate the problem, watch a small
  541.    child trying to find a table in a restaurant.  From the adult point
  542.    of view, the structure of the dining room is seen and an optimal
  543.    route easily chosen.  The child, however, is presented with a set of
  544.    paths between tables where a good path, let alone the optimal one to
  545.    the goal is not discernible.
  546.  
  547.    A little more background might be appropriate.  IP gateways (more
  548.    correctly routers) are boxes which have connections to multiple
  549.    networks and pass traffic between these nets.  They decide how the
  550.    packet is to be sent based on the information in the IP header of the
  551.    packet and the state of the network.  Each interface on a router has
  552.    an unique address appropriate to the network to which it is
  553.    connected.  The information in the IP header which is used is
  554.    primarily the destination address.  Other information (e.g., type of
  555.    service) is largely ignored at this time.  The state of the network
  556.    is determined by the routers passing information among themselves.
  557.    The distribution of the database (what each node knows), the form of
  558.    the updates, and metrics used to measure the value of a connection,
  559.    are the parameters which determine the characteristics of a routing
  560.    protocol.
  561.  
  562.    Under some algorithms, each node in the network has complete
  563.  
  564.  
  565.  
  566. Krol                                                           [Page 10]
  567.  
  568. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  569.  
  570.  
  571.    knowledge of the state of the network (the adult algorithm).  This
  572.    implies the nodes must have larger amounts of local storage and
  573.    enough CPU to search the large tables in a short enough time
  574.    (remember, this must be done for each packet).  Also, routing updates
  575.    usually contain only changes to the existing information (or you
  576.    spend a large amount of the network capacity passing around megabyte
  577.    routing updates).  This type of algorithm has several problems.
  578.    Since the only way the routing information can be passed around is
  579.    across the network and the propagation time is non-trivial, the view
  580.    of the network at each node is a correct historical view of the
  581.    network at varying times in the past.  (The adult algorithm, but
  582.    rather than looking directly at the dining area, looking at a
  583.    photograph of the dining room.  One is likely to pick the optimal
  584.    route and find a bus-cart has moved in to block the path after the
  585.    photo was taken).  These inconsistencies can cause circular routes
  586.    (called routing loops) where once a packet enters it is routed in a
  587.    closed path until its time to live (TTL) field expires and it is
  588.    discarded.
  589.  
  590.    Other algorithms may know about only a subset of the network.  To
  591.    prevent loops in these protocols, they are usually used in a
  592.    hierarchical network.  They know completely about their own area, but
  593.    to leave that area they go to one particular place (the default
  594.    gateway).  Typically these are used in smaller networks (campus or
  595.    regional).
  596.  
  597.    Routing protocols in current use:
  598.  
  599.    Static (no protocol-table/default routing)
  600.  
  601.       Don't laugh.  It is probably the most reliable, easiest to
  602.       implement, and least likely to get one into trouble for a small
  603.       network or a leaf on the Internet.  This is, also, the only method
  604.       available on some CPU-operating system combinations.  If a host is
  605.       connected to an Ethernet which has only one gateway off of it, one
  606.       should make that the default gateway for the host and do no other
  607.       routing.  (Of course, that gateway may pass the reachability
  608.       information somehow on the other side of itself.)
  609.  
  610.       One word of warning, it is only with extreme caution that one
  611.       should use static routes in the middle of a network which is also
  612.       using dynamic routing.  The routers passing dynamic information
  613.       are sometimes confused by conflicting dynamic and static routes.
  614.       If your host is on an ethernet with multiple routers to other
  615.       networks on it and the routers are doing dynamic routing among
  616.       themselves, it is usually better to take part in the dynamic
  617.       routing than to use static routes.
  618.  
  619.  
  620.  
  621.  
  622. Krol                                                           [Page 11]
  623.  
  624. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  625.  
  626.  
  627.    RIP
  628.  
  629.       RIP is a routing protocol based on XNS (Xerox Network System)
  630.       adapted for IP networks.  It is used by many routers (Proteon,
  631.       cisco, UB...) and many BSD Unix systems.  BSD systems typically
  632.       run a program called "routed" to exchange information with other
  633.       systems running RIP.  RIP works best for nets of small diameter
  634.       (few hops) where the links are of equal speed.  The reason for
  635.       this is that the metric used to determine which path is best is
  636.       the hop-count.  A hop is a traversal across a gateway.  So, all
  637.       machines on the same Ethernet are zero hops away.  If a router
  638.       connects connects two networks directly, a machine on the other
  639.       side of the router is one hop away.  As the routing information is
  640.       passed through a gateway, the gateway adds one to the hop counts
  641.       to keep them consistent across the network.  The diameter of a
  642.       network is defined as the largest hop-count possible within a
  643.       network.  Unfortunately, a hop count of 16 is defined as infinity
  644.       in RIP meaning the link is down.  Therefore, RIP will not allow
  645.       hosts separated by more than 15 gateways in the RIP space to
  646.       communicate.
  647.  
  648.       The other problem with hop-count metrics is that if links have
  649.       different speeds, that difference is not reflected in the hop-
  650.       count.  So a one hop satellite link (with a .5 sec delay) at 56kb
  651.       would be used instead of a two hop T1 connection.  Congestion can
  652.       be viewed as a decrease in the efficacy of a link.  So, as a link
  653.       gets more congested, RIP will still know it is the best hop-count
  654.       route and congest it even more by throwing more packets on the
  655.       queue for that link.
  656.  
  657.       RIP was originally not well documented in the community and people
  658.       read BSD code to find out how RIP really worked.  Finally, it was
  659.       documented in RFC-1058.
  660.  
  661.    Routed
  662.  
  663.       The routed program, which does RIP for 4.2BSD systems, has many
  664.       options.  One of the most frequently used is: "routed -q" (quiet
  665.       mode) which means listen to RIP information, but never broadcast
  666.       it.  This would be used by a machine on a network with multiple
  667.       RIP speaking gateways.  It allows the host to determine which
  668.       gateway is best (hopwise) to use to reach a distant network.  (Of
  669.       course, you might want to have a default gateway to prevent having
  670.       to pass all the addresses known to the Internet around with RIP.)
  671.  
  672.       There are two ways to insert static routes into routed; the
  673.       /etc/gateways file, and the "route add" command.  Static routes
  674.       are useful if you know how to reach a distant network, but you are
  675.  
  676.  
  677.  
  678. Krol                                                           [Page 12]
  679.  
  680. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  681.  
  682.  
  683.       not receiving that route using RIP.  For the most part the "route
  684.       add" command is preferable to use.  The reason for this is that
  685.       the command adds the route to that machine's routing table but
  686.       does not export it through RIP.  The /etc/gateways file takes
  687.       precedence over any routing information received through a RIP
  688.       update.  It is also broadcast as fact in RIP updates produced by
  689.       the host without question, so if a mistake is made in the
  690.       /etc/gateways file, that mistake will soon permeate the RIP space
  691.       and may bring the network to its knees.
  692.  
  693.       One of the problems with routed is that you have very little
  694.       control over what gets broadcast and what doesn't.  Many times in
  695.       larger networks where various parts of the network are under
  696.       different administrative controls, you would like to pass on
  697.       through RIP only nets which you receive from RIP and you know are
  698.       reasonable.  This prevents people from adding IP addresses to the
  699.       network which may be illegal and you being responsible for passing
  700.       them on to the Internet.  This type of reasonability checks are
  701.       not available with routed and leave it usable, but inadequate for
  702.       large networks.
  703.  
  704.    Hello (RFC-891)
  705.  
  706.       Hello is a routing protocol which was designed and implemented in
  707.       a experimental software router called a "Fuzzball" which runs on a
  708.       PDP-11.  It does not have wide usage, but is the routing protocol
  709.       formerly used on the initial NSFNET backbone.  The data
  710.       transferred between nodes is similar to RIP (a list of networks
  711.       and their metrics).  The metric, however, is milliseconds of
  712.       delay.  This allows Hello to be used over nets of various link
  713.       speeds and performs better in congestive situations.
  714.  
  715.       One of the most interesting side effects of Hello based networks
  716.       is their great timekeeping ability.  If you consider the problem
  717.       of measuring delay on a link for the metric, you find that it is
  718.       not an easy thing to do.  You cannot measure round trip time since
  719.       the return link may be more congested, of a different speed, or
  720.       even not there.  It is not really feasible for each node on the
  721.       network to have a builtin WWV (nationwide radio time standard)
  722.       receiver.  So, you must design an algorithm to pass around time
  723.       between nodes over the network links where the delay in
  724.       transmission can only be approximated.  Hello routers do this and
  725.       in a nationwide network maintain synchronized time within
  726.       milliseconds. (See also the Network Time Protocol, RFC-1059.)
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734. Krol                                                           [Page 13]
  735.  
  736. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  737.  
  738.  
  739.    Gateway Gateway Protocol (GGP RFC-823)
  740.  
  741.       The core gateways originally used GGP to exchange information
  742.       among themselves.  This is a "distance-vector" algorithm.  The new
  743.       core gateways use a "link-state" algorithm.
  744.  
  745.    NSFNET SPF (RFC-1074)
  746.  
  747.       The current NSFNET Backbone routers use a version of the ANSI IS-
  748.       IS and ISO ES-IS routing protocol.  This is a "shortest path
  749.       first" (SPF) algorithm which is in the class of "link-state"
  750.       algorithms.
  751.  
  752.    Exterior Gateway Protocol (EGP RFC-904)
  753.  
  754.       EGP is not strictly a routing protocol, it is a reachability
  755.       protocol.  It tells what nets can be reached through what gateway,
  756.       but not how good the connection is.  It is the standard by which
  757.       gateways exchange network reachability information with the core
  758.       gateways.  It is generally used between autonomous systems.  There
  759.       is a metric passed around by EGP, but its usage is not
  760.       standardized formally.  The metric's value ranges from 0 to 255
  761.       with smaller values considered "better".  Some implementations
  762.       consider the value 255 to mean unreachable.  Many routers talk EGP
  763.       so they can be used to interface to routers of different
  764.       manufacture or operated by different administrations.  For
  765.       example, when a router of the NSFNET Backbone exchanges routing or
  766.       reachability information with a gateway of a regional network EGP
  767.       is used.
  768.  
  769.    Gated
  770.  
  771.       So we have regional and campus networks talking RIP among
  772.       themselves and the DDN and NSFNET speaking EGP.  How do they
  773.       interoperate?  In the beginning, there was static routing.  The
  774.       problem with doing static routing in the middle of the network is
  775.       that it is broadcast to the Internet whether it is usable or not.
  776.       Therefore, if a net becomes unreachable and you try to get there,
  777.       dynamic routing will immediately issue a net unreachable to you.
  778.       Under static routing the routers would think the net could be
  779.       reached and would continue trying until the application gave up
  780.       (in 2 or more minutes).  Mark Fedor, then of Cornell, attempted to
  781.       solve these problems with a replacement for routed called gated.
  782.  
  783.       Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and
  784.       Hello to Hello'ers.  These speakers frequently all live on one
  785.       Ethernet, but luckily (or unluckily) cannot understand each others
  786.       ruminations.  In addition, under configuration file control it can
  787.  
  788.  
  789.  
  790. Krol                                                           [Page 14]
  791.  
  792. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  793.  
  794.  
  795.       filter the conversion.  For example, one can produce a
  796.       configuration saying announce RIP nets via Hello only if they are
  797.       specified in a list and are reachable by way of a RIP broadcast as
  798.       well.  This means that if a rogue network appears in your local
  799.       site's RIP space, it won't be passed through to the Hello side of
  800.       the world.  There are also configuration options to do static
  801.       routing and name trusted gateways.
  802.  
  803.       This may sound like the greatest thing since sliced bread, but
  804.       there is a catch called metric conversion.  You have RIP measuring
  805.       in hops, Hello measuring in milliseconds, and EGP using arbitrary
  806.       small numbers.  The big questions is how many hops to a
  807.       millisecond, how many milliseconds in the EGP number 3....  Also,
  808.       remember that infinity (unreachability) is 16 to RIP, 30000 or so
  809.       to Hello, and 8 to the DDN with EGP.  Getting all these metrics to
  810.       work well together is no small feat.  If done incorrectly and you
  811.       translate an RIP of 16 into an EGP of 6, everyone in the ARPANET
  812.       will still think your gateway can reach the unreachable and will
  813.       send every packet in the world your way.  Gated is available via
  814.       anonymous FTP from devvax.tn.cornell.edu in directory pub/gated.
  815.  
  816. Names
  817.  
  818.    All routing across the network is done by means of the IP address
  819.    associated with a packet.  Since humans find it difficult to remember
  820.    addresses like 128.174.5.50, a symbolic name register was set up at
  821.    the NIC where people would say, "I would like my host to be named
  822.    uiucuxc".  Machines connected to the Internet across the nation would
  823.    connect to the NIC in the middle of the night, check modification
  824.    dates on the hosts file, and if modified, move it to their local
  825.    machine.  With the advent of workstations and micros, changes to the
  826.    host file would have to be made nightly.  It would also be very labor
  827.    intensive and consume a lot of network bandwidth.  RFC-1034 and a
  828.    number of others describe Domain Name Service (DNS), a distributed
  829.    data base system for mapping names into addresses.
  830.  
  831.    We must look a little more closely into what's in a name.  First,
  832.    note that an address specifies a particular connection on a specific
  833.    network.  If the machine moves, the address changes.  Second, a
  834.    machine can have one or more names and one or more network addresses
  835.    (connections) to different networks.  Names point to a something
  836.    which does useful work (i.e., the machine) and IP addresses point to
  837.    an interface on that provider.  A name is a purely symbolic
  838.    representation of a list of addresses on the network.  If a machine
  839.    moves to a different network, the addresses will change but the name
  840.    could remain the same.
  841.  
  842.    Domain names are tree structured names with the root of the tree at
  843.  
  844.  
  845.  
  846. Krol                                                           [Page 15]
  847.  
  848. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  849.  
  850.  
  851.    the right.  For example:
  852.  
  853.                              uxc.cso.uiuc.edu
  854.  
  855.    is a machine called "uxc" (purely arbitrary), within the subdomains
  856.    of the U of I, and "uiuc" (the University of Illinois at Urbana),
  857.    registered with "edu" (the set of educational institutions).
  858.  
  859.    A simplified model of how a name is resolved is that on the user's
  860.    machine there is a resolver.  The resolver knows how to contact
  861.    across the network a root name server.  Root servers are the base of
  862.    the tree structured data retrieval system.  They know who is
  863.    responsible for handling first level domains (e.g., 'edu').  What
  864.    root servers to use is an installation parameter. From the root
  865.    server the resolver finds out who provides 'edu' service.  It
  866.    contacts the 'edu' name server which supplies it with a list of
  867.    addresses of servers for the subdomains (like 'uiuc').  This action
  868.    is repeated with the sub-domain servers until the final subdomain
  869.    returns a list of addresses of interfaces on the host in question.
  870.    The user's machine then has its choice of which of these addresses to
  871.    use for communication.
  872.  
  873.    A group may apply for its own domain name (like 'uiuc' above).  This
  874.    is done in a manner similar to the IP address allocation.  The only
  875.    requirements are that the requestor have two machines reachable from
  876.    the Internet, which will act as name servers for that domain.  Those
  877.    servers could also act as servers for subdomains or other servers
  878.    could be designated as such.  Note that the servers need not be
  879.    located in any particular place, as long as they are reachable for
  880.    name resolution.  (U of I could ask Michigan State to act on its
  881.    behalf and that would be fine.)  The biggest problem is that someone
  882.    must do maintenance on the database.  If the machine is not
  883.    convenient, that might not be done in a timely fashion.  The other
  884.    thing to note is that once the domain is allocated to an
  885.    administrative entity, that entity can freely allocate subdomains
  886.    using what ever manner it sees fit.
  887.  
  888.    The Berkeley Internet Name Domain (BIND) Server implements the
  889.    Internet name server for UNIX systems.  The name server is a
  890.    distributed data base system that allows clients to name resources
  891.    and to share that information with other network hosts.  BIND is
  892.    integrated with 4.3BSD and is used to lookup and store host names,
  893.    addresses, mail agents, host information, and more.  It replaces the
  894.    /etc/hosts file or host name lookup.  BIND is still an evolving
  895.    program.  To keep up with reports on operational problems, future
  896.    design decisions, etc., join the BIND mailing list by sending a
  897.    request to Bind-Request@UCBARPA.BERKELEY.EDU.  BIND can also be
  898.    obtained via anonymous FTP from ucbarpa.berkeley.edu.
  899.  
  900.  
  901.  
  902. Krol                                                           [Page 16]
  903.  
  904. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  905.  
  906.  
  907.    There are several advantages in using BIND.  One of the most
  908.    important is that it frees a host from relying on /etc/hosts being up
  909.    to date and complete.  Within the .uiuc.edu domain, only a few hosts
  910.    are included in the host table distributed by SRI.  The remainder are
  911.    listed locally within the BIND tables on uxc.cso.uiuc.edu (the server
  912.    machine for most of the .uiuc.edu domain).  All are equally reachable
  913.    from any other Internet host running BIND, or any DNS resolver.
  914.  
  915.    BIND can also provide mail forwarding information for interior hosts
  916.    not directly reachable from the Internet.  These hosts an either be
  917.    on non-advertised networks, or not connected to an IP network at all,
  918.    as in the case of UUCP-reachable hosts (see RFC-974).  More
  919.    information on BIND is available in the "Name Server Operations Guide
  920.    for BIND" in UNIX System Manager's Manual, 4.3BSD release.
  921.  
  922.    There are a few special domains on the network, like NIC.DDN.MIL.
  923.    The hosts database at the NIC.  There are others of the form
  924.    NNSC.NSF.NET.  These special domains are used sparingly, and require
  925.    ample justification.  They refer to servers under the administrative
  926.    control of the network rather than any single organization.  This
  927.    allows for the actual server to be moved around the net while the
  928.    user interface to that machine remains constant.  That is, should BBN
  929.    relinquish control of the NNSC, the new provider would be pointed to
  930.    by that name.
  931.  
  932.    In actuality, the domain system is a much more general and complex
  933.    system than has been described.  Resolvers and some servers cache
  934.    information to allow steps in the resolution to be skipped.
  935.    Information provided by the servers can be arbitrary, not merely IP
  936.    addresses.  This allows the system to be used both by non-IP networks
  937.    and for mail, where it may be necessary to give information on
  938.    intermediate mail bridges.
  939.  
  940. What's wrong with Berkeley Unix
  941.  
  942.    University of California at Berkeley has been funded by DARPA to
  943.    modify the Unix system in a number of ways.  Included in these
  944.    modifications is support for the Internet protocols.  In earlier
  945.    versions (e.g., BSD 4.2) there was good support for the basic
  946.    Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform
  947.    nicely on IP Ethernets and smaller Internets.  There were
  948.    deficiencies, however, when it was connected to complicated networks.
  949.    Most of these problems have been resolved under the newest release
  950.    (BSD 4.3).  Since it is the springboard from which many vendors have
  951.    launched Unix implementations (either by porting the existing code or
  952.    by using it as a model), many implementations (e.g., Ultrix) are
  953.    still based on BSD 4.2.  Therefore, many implementations still exist
  954.    with the BSD 4.2 problems.  As time goes on, when BSD 4.3 trickles
  955.  
  956.  
  957.  
  958. Krol                                                           [Page 17]
  959.  
  960. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  961.  
  962.  
  963.    through vendors as new release, many of the problems will be
  964.    resolved.  Following is a list of some problem scenarios and their
  965.    handling under each of these releases.
  966.  
  967.    ICMP redirects
  968.  
  969.       Under the Internet model, all a system needs to know to get
  970.       anywhere in the Internet is its own address, the address of where
  971.       it wants to go, and how to reach a gateway which knows about the
  972.       Internet.  It doesn't have to be the best gateway.  If the system
  973.       is on a network with multiple gateways, and a host sends a packet
  974.       for delivery to a gateway which feels another directly connected
  975.       gateway is more appropriate, the gateway sends the sender a
  976.       message.  This message is an ICMP redirect, which politely says,
  977.       "I'll deliver this message for you, but you really ought to use
  978.       that gateway over there to reach this host".  BSD 4.2 ignores
  979.       these messages.  This creates more stress on the gateways and the
  980.       local network, since for every packet sent, the gateway sends a
  981.       packet to the originator.  BSD 4.3 uses the redirect to update its
  982.       routing tables, will use the route until it times out, then revert
  983.       to the use of the route it thinks is should use.  The whole
  984.       process then repeats, but it is far better than one per packet.
  985.  
  986.    Trailers
  987.  
  988.       An application (like FTP) sends a string of octets to TCP which
  989.       breaks it into chunks, and adds a TCP header.  TCP then sends
  990.       blocks of data to IP which adds its own headers and ships the
  991.       packets over the network.  All this prepending of the data with
  992.       headers causes memory moves in both the sending and the receiving
  993.       machines.  Someone got the bright idea that if packets were long
  994.       and they stuck the headers on the end (they became trailers), the
  995.       receiving machine could put the packet on the beginning of a page
  996.       boundary and if the trailer was OK merely delete it and transfer
  997.       control of the page with no memory moves involved.  The problem is
  998.       that trailers were never standardized and most gateways don't know
  999.       to look for the routing information at the end of the block.  When
  1000.       trailers are used, the machine typically works fine on the local
  1001.       network (no gateways involved) and for short blocks through
  1002.       gateways (on which trailers aren't used).  So TELNET and FTP's of
  1003.       very short files work just fine and FTP's of long files seem to
  1004.       hang.  On BSD 4.2 trailers are a boot option and one should make
  1005.       sure they are off when using the Internet.  BSD 4.3 negotiates
  1006.       trailers, so it uses them on its local net and doesn't use them
  1007.       when going across the network.
  1008.  
  1009.  
  1010.  
  1011.  
  1012.  
  1013.  
  1014. Krol                                                           [Page 18]
  1015.  
  1016. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  1017.  
  1018.  
  1019.    Retransmissions
  1020.  
  1021.       TCP fires off blocks to its partner at the far end of the
  1022.       connection.  If it doesn't receive an acknowledgement in a
  1023.       reasonable amount of time it retransmits the blocks.  The
  1024.       determination of what is reasonable is done by TCP's
  1025.       retransmission algorithm.
  1026.  
  1027.       There is no correct algorithm but some are better than others,
  1028.       where worse is measured by the number of retransmissions done
  1029.       unnecessarily.  BSD 4.2 had a retransmission algorithm which
  1030.       retransmitted quickly and often.  This is exactly what you would
  1031.       want if you had a bunch of machines on an Ethernet (a low delay
  1032.       network of large bandwidth).  If you have a network of relatively
  1033.       longer delay and scarce bandwidth (e.g., 56kb lines), it tends to
  1034.       retransmit too aggressively.  Therefore, it makes the networks and
  1035.       gateways pass more traffic than is really necessary for a given
  1036.       conversation.  Retransmission algorithms do adapt to the delay of
  1037.       the network after a few packets, but 4.2's adapts slowly in delay
  1038.       situations.  BSD 4.3 does a lot better and tries to do the best
  1039.       for both worlds.  It fires off a few retransmissions really
  1040.       quickly assuming it is on a low delay network, and then backs off
  1041.       very quickly.  It also allows the delay to be about 4 minutes
  1042.       before it gives up and declares the connection broken.
  1043.  
  1044.       Even better than the original 4.3 code is a version of TCP with a
  1045.       retransmission algorithm developed by Van Jacobson of LBL.  He did
  1046.       a lot of research into how the algorithm works on real networks
  1047.       and modified it to get both better throughput and be friendlier to
  1048.       the network.  This code has been integrated into the later
  1049.       releases of BSD 4.3 and can be fetched anonymously from
  1050.       ucbarpa.berkeley.edu in directory 4.3.
  1051.  
  1052.    Time to Live
  1053.  
  1054.       The IP packet header contains a field called the time to live
  1055.       (TTL) field.  It is decremented each time the packet traverses a
  1056.       gateway.  TTL was designed to prevent packets caught in routing
  1057.       loops from being passed forever with no hope of delivery.  Since
  1058.       the definition bears some likeness to the RIP hop count, some
  1059.       misguided systems have set the TTL field to 15 because the
  1060.       unreachable flag in RIP is 16.  Obviously, no networks could have
  1061.       more than 15 hops.  The RIP space where hops are limited ends when
  1062.       RIP is not used as a routing protocol any more (e.g., when NSFnet
  1063.       starts transporting the packet).  Therefore, it is quite easy for
  1064.       a packet to require more than 15 hops.  These machines will
  1065.       exhibit the behavior of being able to reach some places but not
  1066.       others even though the routing information appears correct.
  1067.  
  1068.  
  1069.  
  1070. Krol                                                           [Page 19]
  1071.  
  1072. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  1073.  
  1074.  
  1075.       Solving the problem typically requires kernel patches so it may be
  1076.       difficult if source is not available.
  1077.  
  1078. Appendix A - References to Remedial Information
  1079. -----------------------------------------------
  1080.  
  1081.   [1]  Quarterman and Hoskins, "Notable Computer Networks",
  1082.        Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October
  1083.        1986.
  1084.  
  1085.   [2]  Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
  1086.  
  1087.   [3]  Hedrick, C., "Introduction to the Internet Protocols", Via
  1088.        Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,
  1089.        file tcp-ip-intro.doc.
  1090.  
  1091.   [4]  Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
  1092.        and Architecture", Copyright 1988,  by Prentice-Hall, Inc.,
  1093.        Englewood Cliffs, NJ,  07632 ISBN 0-13-470154-2.
  1094.  
  1095. Appendix B - List of Major RFCs
  1096. -------------------------------
  1097.  
  1098. This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds.  This
  1099. is the 30 August 1989 edition of the list.
  1100.  
  1101. RFC-768       User Datagram Protocol (UDP)
  1102. RFC-791       Internet Protocol (IP)
  1103. RFC-792       Internet Control Message Protocol (ICMP)
  1104. RFC-793       Transmission Control Protocol (TCP)
  1105. RFC-821       Simple Mail Transfer Protocol (SMTP)
  1106. RFC-822       Standard for the Format of ARPA Internet Text Messages
  1107. RFC-826       Ethernet Address Resolution Protocol
  1108. RFC-854       Telnet Protocol
  1109. RFC-862       Echo Protocol
  1110. RFC-894       A Standard for the Transmission of IP
  1111.               Datagrams over Ethernet Networks
  1112. RFC-904       Exterior Gateway Protocol
  1113. RFC-919       Broadcasting Internet Datagrams
  1114. RFC-922       Broadcasting Internet Datagrams in the Presence of Subnets
  1115. RFC-950       Internet Standard Subnetting Procedure
  1116. RFC-951       Bootstrap Protocol (BOOTP)
  1117. RFC-959       File Transfer Protocol (FTP)
  1118. RFC-966       Host Groups: A Multicast Extension to the Internet Protocol
  1119. RFC-974       Mail Routing and the Domain System
  1120. RFC-1000      The Request for Comments Reference Guide
  1121. RFC-1009      Requirements for Internet Gateways
  1122. RFC-1010      Assigned Numbers
  1123.  
  1124.  
  1125.  
  1126. Krol                                                           [Page 20]
  1127.  
  1128. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  1129.  
  1130.  
  1131. RFC-1011      Official Internet Protocols
  1132. RFC-1012      Bibliography of Request for Comments 1 through 999
  1133. RFC-1034      Domain Names - Concepts and Facilities
  1134. RFC-1035      Domain Names - Implementation
  1135. RFC-1042      A Standard for the Transmission of IP
  1136.               Datagrams over IEEE 802 Networks
  1137. RFC-1048      BOOTP Vendor Information Extensions
  1138. RFC-1058      Routing Information Protocol
  1139. RFC-1059      Network Time Protocol (NTP)
  1140. RFC-1065      Structure and Identification of
  1141.               Management Information for TCP/IP-based internets
  1142. RFC-1066      Management Information Base for Network
  1143.               Management of TCP/IP-based internets
  1144. RFC-1084      BOOTP Vendor Information Extensions
  1145. RFC-1087      Ethics and the Internet
  1146. RFC-1095      The Common Management Information
  1147.               Services and Protocol over TCP/IP (CMOT)
  1148. RFC-1098      A Simple Network Management Protocol (SNMP)
  1149. RFC-1100      IAB Official Protocol Standards
  1150. RFC-1101      DNS Encoding of Network Names and Other Types
  1151. RFC-1112      Host Extensions for IP Multicasting
  1152. RFC-1117      Internet Numbers
  1153.  
  1154. Note:  This list is a portion of a list of RFC's by topic that may be
  1155. retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of
  1156. course).
  1157.  
  1158. The following list is not necessary for connection to the Internet,
  1159. but is useful in understanding the domain system, mail system, and
  1160. gateways:
  1161.  
  1162. RFC-974        Mail Routing and the Domain System
  1163. RFC-1009       Requirements for Internet Gateways
  1164. RFC-1034       Domain Names - Concepts and Facilities
  1165. RFC-1035       Domain Names - Implementation and Specification
  1166. RFC-1101       DNS Encoding of Network Names and Other Types
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182. Krol                                                           [Page 21]
  1183.  
  1184. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  1185.  
  1186.  
  1187. Appendix C - Contact Points for Network Information
  1188. ---------------------------------------------------
  1189.  
  1190. Network Information Center (NIC)
  1191.  
  1192.       DDN Network Information Center
  1193.       SRI International, Room EJ291
  1194.       333 Ravenswood Avenue
  1195.       Menlo Park, CA 94025
  1196.       (800) 235-3155 or (415) 859-3695
  1197.  
  1198.       NIC@NIC.DDN.MIL
  1199.  
  1200. NSF Network Service Center (NNSC)
  1201.  
  1202.       NNSC
  1203.       BBN Systems and Technology Corporation
  1204.       10 Moulton St.
  1205.       Cambridge, MA 02238
  1206.       (617) 497-3400
  1207.  
  1208.       NNSC@NNSC.NSF.NET
  1209.  
  1210. NSF Network Information Service (NIS)
  1211.  
  1212.       NIS
  1213.       Merit Inc.
  1214.       University of Michigan
  1215.       1075 Beal Avenue
  1216.       Ann Arbor, MI 48109
  1217.       (313) 763-4897
  1218.  
  1219.       INFO@NIS.NSF.NET
  1220.  
  1221. CIC
  1222.  
  1223.       CSNET Coordination and Information Center
  1224.       Bolt Beranek and Newman Inc.
  1225.       10 Moulton Street
  1226.       Cambridge, MA 02238
  1227.       (617) 873-2777
  1228.  
  1229.       INFO@SH.CS.NET
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238. Krol                                                           [Page 22]
  1239.  
  1240. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  1241.  
  1242.  
  1243. Glossary
  1244. --------
  1245.  
  1246.    autonomous system
  1247.  
  1248.       A set of gateways under a single administrative control and using
  1249.       compatible and consistent routing procedures.  Generally speaking,
  1250.       the gateways run by a particular organization.  Since a gateway is
  1251.       connected to two (or more) networks it is not usually correct to
  1252.       say that a gateway is in a network.  For example, the gateways
  1253.       that connect regional networks to the NSF Backbone network are run
  1254.       by Merit and form an autonomous system.  Another example, the
  1255.       gateways that connect campuses to NYSERNET are run by NYSER and
  1256.       form an autonomous system.
  1257.  
  1258.    core gateway
  1259.  
  1260.       The innermost gateways of the Internet.  These gateways have a
  1261.       total picture of the reachability to all networks known to the
  1262.       Internet.  They then redistribute reachability information to
  1263.       their neighbor gateways speaking EGP.  It is from them your EGP
  1264.       agent (there is one acting for you somewhere if you can reach the
  1265.       core of the Internet) finds out it can reach all the nets on the
  1266.       Internet.  Which is then passed to you via Hello, gated, RIP.  The
  1267.       core gateways mostly connect campuses to the ARPANET, or
  1268.       interconnect the ARPANET and the MILNET, and are run by BBN.
  1269.  
  1270.    count to infinity
  1271.  
  1272.       The symptom of a routing problem where routing information is
  1273.       passed in a circular manner through multiple gateways.  Each
  1274.       gateway increments the metric appropriately and passes it on.  As
  1275.       the metric is passed around the loop, it increments to ever
  1276.       increasing values until it reaches the maximum for the routing
  1277.       protocol being used, which typically denotes a link outage.
  1278.  
  1279.    hold down
  1280.  
  1281.       When a router discovers a path in the network has gone down
  1282.       announcing that that path is down for a minimum amount of time
  1283.       (usually at least two minutes).  This allows for the propagation
  1284.       of the routing information across the network and prevents the
  1285.       formation of routing loops.
  1286.  
  1287.    split horizon
  1288.  
  1289.       When a router (or group of routers working in consort) accept
  1290.       routing information from multiple external networks, but do not
  1291.  
  1292.  
  1293.  
  1294. Krol                                                           [Page 23]
  1295.  
  1296. RFC 1118         The Hitchhikers Guide to the Internet    September 1989
  1297.  
  1298.  
  1299.       pass on information learned from one external network to any
  1300.       others.  This is an attempt to prevent bogus routes to a network
  1301.       from being propagated because of gossip or counting to infinity.
  1302.  
  1303.    DDN
  1304.  
  1305.       Defense Data Network the collective name for the ARPANET and
  1306.       MILNET.  Used frequently because although they are seperate
  1307.       networks the operational and informational foci are the same.
  1308.  
  1309. Security Considerations
  1310.  
  1311.    Security and privacy protection is a serious matter and too often
  1312.    nothing is done about it.  There are some known security bugs
  1313.    (especially in access control) in BSD Unix and in some
  1314.    implementations of network services.  The hitchhikers guide does not
  1315.    discuss these issues (too bad).
  1316.  
  1317. Author's Address
  1318.  
  1319.    Ed Krol
  1320.    University of Illinois
  1321.    195 DCL
  1322.    1304 West Springfield Avenue
  1323.    Urbana, IL  61801-4399
  1324.  
  1325.    Phone: (217) 333-7886
  1326.  
  1327.    EMail: Krol@UXC.CSO.UIUC.EDU
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350. Krol                                                           [Page 24]
  1351.